Presentation: Tweet"Exploring light-weight event sourcing"

Currently many business applications are developed using a very database centric approach, often requiring the use of complex and heavy-weight Object-Relational Mappers (ORMs) to make developers productive. Although improvements have been made (through the use of annotations, reflections, conventions) the core issues remain:

• Lack of modularity
• High coupling to the used ORM and/or underlying database, making it unnecessarily hard to use alternative (NoSQL) or multiple databases
• Hard to understand the full application, due to the complexity of the used ORM
• Mutability is in-grained, reducing the possibilities for composition and modularity
• Limited possibility for abstraction, due to limitations imposed by the ORM on used data types, etc.

In this talk we'll explore the use of an alternative approach using the techniques pioneered by Domain-Driven Design (DDD) and especially Command-Query Responsibility Segregation (CQRS): Event Sourcing.

Using Event Sourcing the application can be split into two parts:

• Domain logic responsible for generating events (command side)
• Reporting, view, integration, etc. logic that consumes the generated events ("query" side).

Through this explicit notion of change (domain events) the developer is put back in control of the application.

Traditional languages such as Java require a lot of ceremony when implementing event sourcing, obscuring the basic simplicity. Using Scala's flexible syntax and support for light-weight classes, immutable data structures and transactional memory only very little support code is needed to build production ready applications using Event Sourcing. We can start simple and scale up to more complexity only when needed. During this talk we'll take a quick tour through the code you might need to get started.

The goals are to make developers productive while keeping applications understandable and maintainable. This is achieved by:

• Putting the developer back into control, instead of a framework
• Keeping infrastructure concerns out of your domain code
• Manage complexity in a scalable manner. Simple functionality ("CRUD") is easy to implement, while allowing a clear path towards complex behavior and implementation
• A simple cost model: the cost of generating, storing, and processing events is clear, as is the cost for querying derived data. With relational databases and ORMs costs are much less clear and often highly dependent on external factors such as configuration, table statistics, etc.
• Simple, clearly delineated application components that interact through well-defined interfaces, for both infrastructure and domain code
• Mostly immutable data structures with mutation controlled by using Scala's software transactional memory

Some of these concepts were first explored in a series of blog posts and was presentated at ScalaDays in 2011 at Standford University in California.